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DETAILED ACTION 

1 . Applicant's amendment and response dated June 01 , 2009 in responding 
to the Office Action of December 31 , 2008 provided in the rejection of all pending 
claims 1-4, 6-16, and 18. 

No claims have been cancelled nor added. 

Therefore, claims 1-4, 6-16, and 18 are presented for examination. 

2. Applicant's arguments for the claims have been fully considered but they 
are not persuasive, as will be addressed under Prior Art's Arguments - rejections 
section at item (3) below. Thus, the rejection of the claims over prior art in the 
previous Office Action is maintained with the additional clarification hereon 
accordingly, THIS ACTION IS MADE FINAL. See MPEP §706.07(a). Applicant 
is reminded of the extension of time policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire 
THREE MONTHS from the mailing date of this action. In the event a first reply is 
filed within TWO MONTHS of the mailing date of this final action and the advisory 
action is not mailed until after the end of the THREE-MONTH shortened statutory 
period, then the shortened statutory period will expire on the date the advisory 
action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will 
the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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Prior Art's Arguments - Rejections 

3. Applicant' arguments filed on June 01 , 2009 have been fully considered 
but they are not persuasive as set forth below: 

As to claim 1 , Applicant contends that "[w]hile Baisley, Haikin, Murakami, 
and Boxall generally relate to compiling source code and/or debugging code, 
they fail-whether cited alone or in combination-to disclose or reasonably 
support the pending claims as recited in their entireties. For example, among 
other things, the cited art fails to disclose or reasonably support extracting at the 
time of compiling a port number identifying a port of the server on which the 
source code may be accessed." -- See Remarks, page 7, ^4, and page 8, U 1, 
by merely attacking on Boxall alone (e.g. Remarks, page 7, ^ 2-4 and page 9, U 
1), which examiner respectfully disagrees. 

First of all, in response to applicant's arguments against the references 
individually, one cannot show nonobviousness by attacking references 
individually where the rejections are based on combinations of references. See 
In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 
F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986), while examiner's rejections; on the 
other hand, are based on the combination of teaching among Baisley, Haikin, 
Murakami, and Boxall - See previous Office action (i.e. pages 3-8). Accordingly, 
Applicant's above argument are unpersuasive argument: arguing against 
references individually. 

It is to note that, Baisley teaches, 
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"[A] compiler that has been programmed with the use of objects must 
relate its objects (representing a program being compiled) to locations within the 
source files. The parsing phase of compilation creates objects representing 
program elements, such as functions, statements and expressions. The code 
generation phase of compilation involves generating machine instruction objects 
for the program element objects. Locations in the source files must be 
captured and maintained for the program element objects and then passed on to 
the respective machine instruction objects. A source location usually consists 
of a source file name and a line number within the source file. The compiler 
uses the source locations of its objects in at least two cases. First, the compiler 
shows a source location when issuing a diagnostic message to inform the 
compiler's user of an error location. Secondly, the compiler places a table in the 
binary file with the machine instructions mapping the instructions to their 
corresponding source locations . This table is used for debugging when the 
machine instructions are loaded from the binary file into a computer system's 
memory and executed. If processing of the machine instructions is interrupted, 
a debugger or other diagnostic software can use the table to find the source... 
The compiler 20, which has been programmed using objects, must relate 
its objects (representing a program being compiled) to locations within the 
source files 22. The parsing phase of compilation creates objects representing 
program elements, such as functions 23, statements 24 and expressions 25-27. 
A source location of one of these objects is generally shown as a source file 
name and a line number within the named source file. The code generation 
phase of compilation involves generating machine instruction objects for the 
program element objects. The source location of a machine instruction object is 
generally the same as the source location of the statement or expression for 
which the machine instruction was generated." - See at least col. 1: 50-62 and 
col. 5: 20-30 with emphasis added. 



As can be seen from above teaching by Baisely, during parsing step, 
compiler does capture (extract) location of a source file such as source file 
name and line number. It is also to note that "the captured (extracted) 
information" is being store as (i.e. mapping table of the compiler to be later used 
during binary debugging. 

As mentioned in the previous Office action (i.e. page 5-7), 

"It is noted that Baisley does not explicitly disclose storing a source code 
file {source files 22, Fig. 1, which contains program elements (e.g., function 
23...), - See at least col. 5: 14-17 and col. 1: 24-28) on a server, the source code 
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file including source code and being associated with a version. The extracting 
information identifying the version associated with the source code file, a numeric 
number that indicates a version number of the source code. 

However, Haikin, in an analogous art, teaches a software source code 
version control system for use during the development and maintenance of a 
software system by multiple software developer in which historical version 
tracking is maintained for all source code on a line-by-line basis on central server 
20, Fig. 1 , without requiring excessive storage area, in which source code can be 
accessed and modified by more than one software developer at a time, in which 
historical version tracking of a broad functional changes is provided and in which 
quick and transparent access is provided to each version of the source code 
(e.g., 2.0) (see Haikin, at least col. 3: 21-31, col. 7: 20-42, and col. 8: 23-59 with 
emphasis added). 

It would have been obvious to one ordinary skill in the art at the time the 
invention was made to use the source code version control system of Haikin in 
source code files 22 (fig. 1 ) of Baisley for providing storing of each version the 
source code and providing quick access (retrieving) and maintaining of the 
historical version for all source code without requiring excess storage space as 
taught in Haikin (e.g., col. 3: 1-18). 

As indicate above, Baisley while compiling the source code file, extracting 
information (e.g. table mapping instructions to source code location) that 
identified a location of the source code file and the version (e.g., source file 
name) associated with the source code file - see Baisley, at least col. 5: 20-30. 

It is to note that modified Baisley and Haikin do not explicitly disclose 
extracting information that included a name of server, a path to the source code. 
However, Murakami, in an analogous art, teaches testing consistency of machine 
code file and source files . "[t]he computer system compiles a source code in the 
source file 1 into a machine code 3a ( step S1), thus producing a machine code 
file 3. At the same time, the computer system collects file attributes (step s2) of 
the source file 1 (e.g., source file attribute 32 (fig. 10) such as i.e. location : 
http//sv1/mas/sorc/pag.c ..\ which includes, for example, the following 
information: file location 2a, last modified date 2b, and file size 2c. The file 
location 2a indicates where the source file 1 is stored. The last modified date 2b 
shows when the source file 1 was modified last time" - See Murakami, at least, 
[0035], [0079], and (source file attribute 32) of Fig. 10, with emphasis added. 

It would have been obvious to one ordinary skill in the art at the time 
invention was made to use the source file attribute (e.g. file 32 of Fig. 10) of 
Murakami in the mapping table of the modified Baisley and Haikin for optimizing 
consistency between the debugging files with the source files as taught in 
Murakami (e.g., [0002]). 

It is to note that modified Baisley with Haikin, and Murakami do not 
explicitly disclose extracting information that includes a port number of the server 
at which the server may be accessed to access the source code. However, 
Boxall, in an analogous art, teaches remote debugging system for client/server 
application. By providing parameters passing to the remote debugger Ul 19, 
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which the parameter includes ... a port number identifying the port on which the 
debugger Ul is listening/accessing. - See Boxall, at least, title, and col. 6: 43-52 
with emphasis added. 

It would have been obvious to one ordinary skill in the art at the time 
invention was made to include parameter (e.g., port number) of Murakami in the 
mapping table of the modified Baisley with Haikin for quickly remote access 
location to each individual version source code during mapping between the 
debugging files with the source files." , with emphasis added. 



Accordingly, the combination of Baisley with Haikin, Murakami, and Boxall 
does teach the above claimed limitation. 

As of independent claim 1 1 , Applicant appears to argue similar to claim 1 

- See Remarks page 9, last paragraph. Further Applicant contend that, 

"With regard to claim 1 1 , Applicant respectfully submits that the Office has 
failed to assert, much less provide, a prima facie case of obviousness. As 
reflected on page 8 of the Office Action, the full basis of rejection for claim 1 1 is 
based on reference to the method of claim 1. (i.e., "Haikin also discloses a 
system []for implementing the above method). The Office gives no consideration 
to the various elements in claim 1 1 that are not recited within claim 1 . For 
example, claim 1 1 recites: 

• an extractor operating in parallel with the compiler; and 

• plurality of numeric values each indicating a version number of a 
corresponding source code file. 

At no time does the Office consider such elements, particularly "multiple numeric 
values" that are extracted by an extractor "in parallel with the compiler" as recited 
in combination with the are extracted by an extractor "in parallel with the 
compiler" as recited in combination with the other claim elements." - See 
Remarks, page 9, U 1-4, which examiner respectfully disagrees. 



First of all , as of claim 1 1 , recites, "...[an] extractor arrange to operate in 
parallel with the compiler and extract information..." with reasonably broad 
interpretation, are very similar to claim 1 recitation, "... while (in parallel : 
emphasis added) compiling ( performing by compiler : emphasis added), 
extraction information ( being implemented by extractor : emphasis added) 
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Secondary, in responding to "plurality of numeric values each indicating a version 
number of corresponding source code file argument, it is to note, these limitation 
have already been addressed (i.e. claim 1) above. 

"It is noted that Baisley does not explicitly disclose storing a source code 
file (source files 22, Fig. 1, which contains program elements (e.g., function 
23...), - See at least col. 5: 14-17 and col. 1: 24-28) on a server, the source code 
file including source code and being associated with a version. The extracting 
information identifying the version associated with the source code file, a numeric 
number that indicates a version number of the source code. 

However, Haikin, in an analogous art, teaches a software source code 
version control system for use during the development and maintenance of a 
software system by multiple software developer in which historical version 
tracking is maintained for all source code on a line-by-line basis on central server 
20, Fig. 1 . without requiring excessive storage area, in which source code can be 
accessed and modified by more than one software developer at a time, in which 
historical version tracking of a broad functional changes is provided and in which 
quick and transparent access is provided to each version of the source code 
(e.g., 2.0) (see Haikin, at least col. 3: 21-31, col. 7: 20-42, and col. 8: 23-59 with 
emphasis added). 

It would have been obvious to one ordinary skill in the art at the time the 
invention was made to use the source code version control system of Haikin in 
source code files 22 (fig. 1 ) of Baisley for providing storing of each version the 
source code and providing quick access (retrieving ) and maintaining of the 
historical version for all source code without requiring excess storage space as 
taught in Haikin (e.g., col. 3: 1-18)" See previous Office action, at least pages 5-8 
with emphasis added. 



Accordingly, the combination of Baisley with Haikin, Murakami, and Boxall 
does teach claim 1 1 limitation. 

Claim Rejections - 35 USC § 103 
4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as 
set forth in section 102 of this title, if the differences between the subject matter sought to be 
patented and the prior art are such that the subject matter as a whole would have been obvious at 
the time the invention was made to a person having ordinary skill in the art to which said subject 
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matter pertains. Patentability shall not be negatived by the manner in which the invention was 
made. 

5. Claims 1-4, 6-16, and 18 are rejected under 35U.S.C. 103(a) as being 
unpatentable over Baisley et al., (U.S. Patent No. 6,106,574 of record- 
hereinafter Baisley), in view of Haikin (U. S. Patent No. 6,757,893 B1 of record), 
Murakami et al. (US 2003/0167423 A1 of record - hereinafter Murakami ), and 
Boxall et al. (US 6263,456, B1 of record - hereinafter BoxaN). 

As per claims 1 and 11, Baisley discloses a method for associating 
original source code with binary code for debugging the binary code, the method 
comprising: 

storing a source code file (source files 22, Fig. 1, which contains program 
elements (e.g., function 23...), - See at least col. 5: 14-17 and col. 1: 24-28), the 
source code file including source code and being associated with a version (e.g., 
source file name - see at least col. 5: 28-30 with emphasis added); 

compiling the source code file into a binary file (e.g., binary file 36, Fig. 1 ) 
- (e.g., compiler 20 convert the source files 22 into objects 30-34, Fig. 1, which 
represent machine/binary instruction - see at least col. 5: 17-22 with emphasis 
added) ; 

while compiling the source code file, extracting information (e.g. table 
mapping instructions to source code location) that identified a location of the 
source code file and the version (e.g., source file name) associated with the 
source code file — See at least col. 1: 50-62 and col. 5: 20-30 with emphasis 
added. 
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storing the extracted information in a debug file associated with the binary 
file - see at least col. 5: 39-42 with emphasis added; 

after compiling the source code file, receiving an instruction for a 
debugger to debug the binary file - see at least col. 5: 39-51; 

after receiving the instruction for the debugger, using the extracted 
information in the debug file, locating the source code file and associate it with 
the binary file - (e.g., a debugger uses table to find the source location such as 
source file name and a line number- see at least col. 5: 45-51 & 28-30 with 
emphasis added); and 

thereafter debugging the binary file with full source code support by 
correlating lines of the source code file with binary instructions in the binary file, 
the source code file including only the source code originally used to compile the 
binary file (e.g., a debugger uses table to fined the source location such as 
source file name and a line number - see at least col. 5: 45-51 & 28-30 with 
emphasis added). 

It is noted that Baisley does not explicitly disclose storing a source code 
file {source files 22, Fig. 1, which contains program elements (e.g., function 
23...), - See at least col. 5: 14-17 and col. 1: 24-28) on a server, the source code 
file including source code and being associated with a version. The extracting 
information identifying the version associated with the source code file, a numeric 
number that indicates a version number of the source code. 
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However, Haikin, in an analogous art, teaches a software source code 
version control system for use during the development and maintenance of a 
software system by multiple software developer in which historical version 
tracking is maintained for all source code on a line-by-line basis on central server 
20, Fig. 1 . without requiring excessive storage area, in which source code can be 
accessed and modified by more than one software developer at a time, in which 
historical version tracking of a broad functional changes is provided and in which 
quick and transparent access is provided to each version of the source code 
(e.g., 2.0) (see Haikin, at least col. 3: 21-31, col. 7: 20-42, and col. 8: 23-59 with 
emphasis added). 

It would have been obvious to one ordinary skill in the art at the time the 
invention was made to use the source code version control system of Haikin in 
source code files 22 (fig. 1 ) of Baisley for providing storing of each version the 
source code and providing quick access (retrieving ) and maintaining of the 
historical version for all source code without requiring excess storage space as 
taught in Haikin (e.g., col. 3: 1-18). 

As indicate above, Baisley while compiling the source code file, extracting 
information (e.g. table mapping instructions to source code location) that 
identified a location of the source code file and the version (e.g., source file 
name) associated with the source code file - see Baisley, at least col. 5: 20-30. 

It is to note that modified Baisley and Haikin do not explicitly disclose 
extracting information that included a name of server, a path to the source code. 
However, Murakami, in an analogous art, teaches testing consistency of machine 
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code file and source files . "[t]he computer system compiles a source code in the 
source file 1 into a machine code 3a ( step S1), thus producing a machine code 
file 3. At the same time, the computer system collects file attributes (step s2) of 
the source file 1 (e.g., source file attribute 32 (fig. 10) such as i.e. location : 
http//sv1/mas/sorc/pag.c which includes, for example, the following 
information: file location 2a, last modified date 2b, and file size 2c. The file 
location 2a indicates where the source file 1 is stored. The last modified date 2b 
shows when the source file 1 was modified last time" - See Murakami, at least, 
[0035], [0079], and (source file attribute 32) of Fig. 10, with emphasis added. 

It would have been obvious to one ordinary skill in the art at the time 
invention was made to use the source file attribute (e.g. file 32 of Fig. 1 0) of 
Murakami in the mapping table of the modified Baisley and Haikin for optimizing 
consistency between the debugging files with the source files as taught in 
Murakami (e.g., [0002]). 

It is to note that modified Baisley with Haikin, and Murakami do not 
explicitly disclose extracting information that includes a port number of the server 
at which the server may be accessed to access the source code. However, 
Boxall, in an analogous art, teaches remote debugging system for client/server 
application. By providing parameters passing to the remote debugger Ul 19, 
which the parameter includes ... a port number identifying the port on which the 
debugger Ul is listening/accessing. - See Boxall, at least, title, and col. 6: 43-52 
with emphasis added. 
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It would have been obvious to one ordinary skill in the art at the time 
invention was made to include parameter (e.g., port number) of Murakami in the 
mapping table of the modified Baisley with Haikin for quickly remote access 
location to each individual version source code during mapping between the 
debugging files with the source files. 

It is further to note that modified Baisley with Haikin, Murakami, and 
Boxall, does not explicitly disclose a computer-readable storage medium having 
computer executable instructions stored thereon that, when executed by a 
processor, implemented above method. However, Haikin discloses a computer 
storage medium (e.g., removable CD-ROM media - see at least col. 7: 36). 

It is well known in the computer art that such method step can be 
implemented as computer program and be known, commonly practiced and/or 
stored on the removable CD-ROM media of Haikin for implemented the above 
method. Thus, it would have been obvious in view of reference teachings above. 

Further regarding to claim 11, Haikin also discloses a system (e.g., 
workstation 30 (Fig. 3) - see at least col. 8: 46-50) for implementing the above 
method. 

As to claim 12, modified Baisley with Haikin discloses further comprising 
a source server (e.g., source code storage 270 (fig. 2)— see Haikin at least col. 8: 
24-45) arranged to extract the information (e.g., table mapping of Baisley) at 
debug time, retrieve the source code files from the version control server, and 
place the source code files in a directory accessible by the debugger - (e.g., a 
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debugger uses table to find the source location such as source file name and a 
line number- see Baisley, at least col. 5: 45-51 & 28-30 with emphasis added). 
As to claim 2, modified Baisley with Haikin discloses further comprising: 

extracting the information from the debug file -see Baisley, at least col. 5: 
39-42 with emphasis added; 

requesting the source code associated with the version from the server via 
the information (see Baisley, at least col. 5: 20-30); 

placing the source code in a directory used by a debugger to debug the 
executable code -see Baisley, at least col. 5: 39-42 with emphasis added; and 

executing the debugger and matching an instruction in the executable 
code to an instruction in the source code (e.g., a debugger uses table to find the 
source location such as source file name and a line number- see Baisley, at 
least col. 5: 45-51 & 28-30 with emphasis added). 

As to claim 3, modified Baisley with Haikin also discloses wherein the 
source code file includes programming statements {source files 22, Fig. 1, which 
contains program elements (e.g., function 23...), - See Baisley, at least col. 5: 
14-17 and col. 1: 24-28), which, when compiled, produce executable code in the 
form of the binary file - (e.g., compiler 20 convert the source files 22 into objects 
30-34, Fig. 1, which represent machine/binary instruction(e.g., binary file 36, Fig. 
1 ) - see Baisley, at least col. 5: 1 7-22 with emphasis added) 

As to claim 4, modified Baisley with Haikin further discloses wherein the 
server comprises a version control server (e.g., version control server module 
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280, Fig. 2) that stores a plurality of versions of the source code - See Haikin, at 
least col. 8: 38-42. 

As to claim 6, modified Baisley with Haikin also discloses wherein the 
binary file includes code that was compiled form a plurality of source code files 
(e.g., FILE1 , FILE 2...), each source code file associated with a version (e.g., file 
name such as FILE 1 , FILE 2..) - See Baisley, at least col. 8: 38-67 and col. 9: 
1-42 with emphasis added. 

As to claim 7, modified Baisley with Haikin also discloses further 
comprising obtaining additional information that identified the version associated 
with the plurality of source code files to the server and storing the additional 
information in the debug file - See Haikin, at least col. 7: 20-42, col. 8: 38-42, col. 
10: 26-30, and col. 16: 12-50 with emphasis added. 

As per claims 8 and 14, modified Baisley with Haikin further discloses 
wherein the debug file comprises a program database file (e.g., source code 
storage 270 (fig. 2) — see Haikin at least col. 8: 24-45) that is separate form the 
executable code {e.g., binary file 36 (fig. 1) contains machine code instruction - 
see Baisley at least col. 5: 17-22). 

As to claim 9, modified Baisley with Haikin also discloses wherein the 
debug file comprises a portion of an executable file (e.g., machine instruction) 
that includes the executable code - see Baisley, at least col. 5: 17-22 & 42-44. 

As to claim 10, modified Baisley with Haikin disclose further comprising 
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iterating each source code file that is part of a compilation, each source 
code file having a version (see Baisley, at least col. 5: 14-22); 

obtaining information that identified the version of each source code file to 
the server and a local name of each source code file - See Haikin, at least col. 7: 
20-42, col. 8: 38-42, col. 10: 26-30, and col. 16: 12-50 with emphasis added.; 

storing the information in a lookup table (e.g. table mapping instructions to 
source code location -See Baisley, at least col. 5: 20-30 ); and 

extracting, from the binary file, local names of the source code files that 
were used in compiling the binary file - e.g., a debugger uses table to find the 
source location such as source file name and a line number - see Baisley, at 
least col. 5: 45-51 & 28-30 with emphasis added; and 

for each source code file that was used in compiling the binary file, looking 
up the version in the lookup table using the local name of the source code file - 
See Baisley, at least col. 8: 38-67 and col. 9: 1-42 with emphasis added. 

As to claim 13, modified Baisley with Haikin discloses wherein the source 
server comprises a component of the debugger (e.g., table mapping - see 
Baisley, at least col. 5: 45-51 & 28-30 with emphasis added). 

As to claim 15, modified Baisley with Haikin discloses wherein the 
debugger is arranged to find the source code files in the directory and is unaware 
of the version control server (e.g., e.g., a debugger uses table to find the source 
location such as source file name and a line number- see Baisley, at least col. 
5: 45-51 & 28-30 with emphasis added). 
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Claim 16 recites similar limitation of claim 11 above. Accordingly claim16 
is being applied the same rejection as of claim 11 indicated above. 

As to claim 18, Modified Baisley with Haikin, Murakami, and Boxall 
discloses wherein placing the source code in a directory used by the debugger to 
debug the executable code is performed after launching the debugger, and 
wherein the method further discloses: 

storing in the debug file information from a data stream (i.e. location: http: 
//sv1/mas/sorc/pag.c ...) and when the data stream is divided into a global 
variable area (e.g. http, ) , a local variable area (master/server) , and a source 
files area (e.g., pg.c) , the data stream including variable in a shorthand 
expressions requiring an extractor substitute the variables with an expression or 
value identifying information necessary for retrieval of the sour code file ( e.g., 
inserting the source file attribute 32 into XML file ) ; and 

merging the debugging file with the binary file -see Baisley, at least col. 5: 
39-42 with emphasis added. 

Conclusion 

6. The prior art of record and not relied upon, which is cited on (form 892) is 
considered pertinent to application disclosure. 

7. Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to Marina Lee whose telephone number is 
(571 ) 270-1 648. The examiner can normally be reached on M-F (1 1 :00 am to 7: 
30 pm) EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Tuan Q. Dam can be reached on (571) 272-3695. The 
fax phone number for the organization where this application or proceeding is 
assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786- 
9199 (IN USA OR CANADA) or 571-272-1000. 
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Supervisory Patent Examiner, Art Unit 2192 



